Field of the Invention
The invention relates in general to a method for determining debug authorization for a motherboard control module and an associated motherboard control module, and more particularly, to a method for determining debug authorization that determines whether a debug function on a motherboard control module can be activated according to a characteristic match of a chip unique password, and an associated motherboard control module using the method.
Description of the Related Art
When designing chips of a next generation, numerous back-and-forth exchanges regarding the chips are carried out between a motherboard manufacturer (i.e., an integrated circuit design house) and different system manufacturers. During these exchanges, the motherboard manufacturer performs debugging on a flash memory of a motherboard control module, whereas the system manufacturers handle customizations of different data regions (i.e., different modules) of the flash memory. However, debugging on the flash memory face many challenges.
Before a processor start booting with a secure startup chip, a boot code burned in the chip demands a public key pre-published by a system manufacturer to first authenticate a digital signature included in a data block of a flash memory, so as to ensure that the digital signature is generated from encrypting contents of the data block using a corresponding private key by the system manufacturer. Having successfully authenticated the digital signature generated from the private key, the processor then proceeds to an actual boot procedure. It should be noted that, each time data contents of data block of the flash memory are altered, the altered data contents lose their certification as the altered data contents are not encrypted. Further, a debug process of the flash memory needs to be performed under the premise that the digital signature is approved by the foregoing authentication procedure. As a result, when a motherboard manufacturer, after retrieving a motherboard from a system manufacturer, is to perform debugging on the motherboard that is previously manufactured and customized by the system manufacturer, the flash memory may be rejected from debugging, or certification of the flash memory may not be supported due to the lack of a successful authentication although the flash memory is allowed for debugging.
In order to solve the above issues and to perform debugging, after receiving the packaged motherboard from the system manufacturer, common approaches employed by the motherboard manufacturer include the following. In a first method, an original chip is replaced by another chip, which requires no encryption verification by the private key and is burned with the same data as the original chip, so that the verification procedure of the flash memory can be skipped while the data contents of the chip are substantially unchanged. In a second method, the private key for encryption when updating the data contents of the flash memory is obtained from the system manufacturer, and the private key is then utilized for the verification procedure of the flash memory to accordingly perform the subsequent debugging. From manual control procedure perspectives, both of the first and second methods are not only complicated but also tremendously risky due to manual factors involved. For example, in the first method, assume that the replacement chip is burned with a malicious code that illegally accesses and spreads the above digital signature. Since other motherboards of the same model number fabricated by the motherboard manufacturer can also be verified through the same digital signature, with the leaked digital signature, the motherboards of the same model number may be evil-mindedly tampered with the lack of security protection provided by the digital signature. For another example, in the second method, assuming the private key is exposed during a dispatch process of the private key from the system manufacturer to the motherboard manufacturer, the security of motherboards of the same model becomes completely void due to the leaked and abused private key. Consequently, whether to activate debugging of a motherboard faces a dilemma due to security reasons.